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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the PLMN network as it evolves. CM actions have the objective to control and monitor the actual 
configuration on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator 
or by functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service (QoS). The CM actions are 
initiated either as single actions on single NEs of the PLMN network, or as part of a complex procedure involving 
actions on many resources/objects in one or several NEs. 

Clauses 4 to 6 give an introduction and description of the main concepts of CM, which are not mandatory for 
compliance with this specification. Clause 7 contains the specific definitions for the standardised interface Itf-N, which 
are necessary to follow for compliance. 

Clause 4 provides a brief background of CM, while Clause 5 explains CM services available to the operator. Clause 6 
breaks these services down into individual CM functions, which support the defined services. Clause 7 defines the Itf-N 
(see 3GPP TS 32.102 [2]) to be used for CM. 
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Scope 



The present document describes the Configuration Management (CM) aspects of managing a PLMN network. This is 
described from the management perspective in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. 

The present document defines a set of controls to be employed to effect set-up and changes to a PLMN network in such 
a way that operational capability and Quality Of Service (QOS), network integrity and system inter working are 
ensured. In this way, the present document describes the interface definition and behaviour for the management of 
relevant NEs in the context of the described management environment. The context is described for both the 
management system (OS) and Network Element (NE) functionality. 

Clause 7 contains the specific definitions for the standardised Itf-N, which are necessary to follow for compliance to 
this specification. 

The Itf-N for CM is built up by a number of Integration Reference Points (IRPs) and a related Name Convention, which 
realise the functional capabilities over this interface. The basic structure of the IRPs is defined in 3GPP TS 32.150 [9]. 
For CM, a number of IRPs (and a Name Convention [8]) are defined, used by this as well as by other specifications for 
Telecom Management produced by 3GPP. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)". 

[4] ITU-T Recommendation X.721: "Information technology - Open Systems Interconnection - 

Structure of management information: Definition of management information". 

[5] ITU-T Recommendation X.730: "Information technology - Open Systems Interconnection - 

Systems Management: Object Management Function". 

[6] ITU-T Recommendation X.731: "Information technology - Open Systems Interconnection - 

Systems Management: State management function". 

[7] ITU-T Recommendation X.734: "Information technology - Open Systems Interconnection - 

Systems Management: Event report management function". 

[8] 3GPP TS 32.300: "Telecommunication management; Configuration Management (CM); Name 

convention for Managed Objects". 

[9] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.150 [9]. 

Data: is any information or set of information required to give software or equipment or combinations thereof a specific 
state of functionality. 

• Element Manager (EM): See 3GPP TS 32.101 [1]. 

Firmware: is a term used in contrast to software to identify the hard-coded program, which is not downloadable on the 

system. 

Hardware: is each and every tangible item. 

Managed Object (MO): See 3GPP TS 32.150 [9]. 

Managed Object Class (MOC): See 3GPP TS 32.150 [9]. 

Managed Object Instance (MOI): See 3GPP TS 32.150 [9]. 

Management Information Base (MIB): the set of existing managed objects in a management domain, together with 
their attributes, constitutes that management domain's MIB. The MIB may be distributed over several OS/NEs. 

Network Element (NE): See 3GPP TS 32.101 [1]. 

Network Manager (NM): See 3GPP TS 32.101 [1]. 

Network Resource (NR): is a component of a NE, which can be identified as a discrete separate entity and is in an 
object oriented environment for the purpose of management represented by an abstract entity called Managed Object 
(MO). 

Object Management Group (OMG): see http://www.omg.org. 

Operations System (OS): indicates a generic management system, independent of its location level within the 
management hierarchy. 

Operator: is either 

• a human being controlling and managing the network; or 

• a company running a network (the PLMN network operator). 

Optimisation: of the network is each up-date or modification to improve the network handling and/or to enhance 
subscriber satisfaction. The aim is to maximise the performance of the system. 

Re-configuration: is the re-arrangement of the parts, hardware and/or software that make up the PLMN network. A re- 
configuration can be of the parts of a single NE or can be the re-arrangement of the NEs themselves, as the parts of the 
PLMN network. A re-configuration may be triggered by a human operator or by the system itself. 

Reversion: is a procedure by which a configuration, which existed before changes were made, is restored. 

Software: is a term used in contrast to firmware to refer to all programs which can be loaded to and used in a particular 

system. 

Up-Dates: generally consist of software, firmware, equipment and hardware, designed only to consolidate one or more 
modifications to counter-act errors. As such, they do not offer new facilities or features and only apply to existing NEs. 

Up-Grades: can be of the following types: 

• enhancement - the addition of new features or facilities to the PLMN network; 
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extension - the addition of replicas of existing entities. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CM Configuration Management 

CORBA Common Object Request Broker Architecture 

EM Element Manager 

FM Fault Management 

FW Firmware 

HW Hardware 

IOC Information Object Class 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Standardisation Sector 

MIB Management Information Base 

MOC Managed Object Class 

MOI Managed Object Instance 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

OMG Object Management Group 

OS Operations System 

OSF Operations System Function 

PM Performance Management 

RNC Radio Network Controller 

SW Software 

TM Telecom Management 

TRX Transceiver 

UML Unified Modelling Language (OMG) 

4 Network Configuration IVIanagement (CIVI) 



4.1 



General 



In the development of a PLMN network, three general phases can be described which represent different degrees of 
stability. Once the first stage is over, the system will cycle between the second and the third phases. This is known as 
the network life-cycle and includes: 

1) the PLMN network is installed and put into service; 

2) the PLMN network reaches certain stability and is only modified (dynamically) to satisfy short-term 
requirements. E.g. by (dynamic) re-configuration of resources or parameter modification; this stable state of a 
PLMN network cannot be regarded as the final one because each equipment or SW modification will let the 
PLMN network progress to an unstable state and require optimisation actions again; 

3) the PLMN network is being adjusted to meet the long-term requirements of the network operator and the 
customer, e.g. with regard to performance, capacity and customer satisfaction through the enhancement of the 
network or equipment up-grade. 

During these phases, the operators will require adequate management functions to perform the necessary tasks. 

4.1 .1 Installing a PLMN network 

When a 3G network is installed and initialised for the first time, all NEs need to be introduced to the NM, the data for 
initialisation and SW for proper functioning need to be provided. All these actions are carried out to create NEs and to 
initialise them. 



£75/ 



3GPP TS 32.600 version 1 0.0.0 Release 1 8 ETSI TS 1 32 600 V1 0.0.0 (201 1 -05) 



4.1 .2 Operating a PLMN network 



Whilst in service, the operator needs to react to short-term incidents such as traffic load requirements, which are 
different from the current network capabilities, NEs/NRs need to be re-configured and parameters need to be adapted to 
follow these day-to-day requirements. 

4.1 .3 Growing/pruning a PLMN network 

As the PLMN network grows and matures new equipment is installed and understanding of system behaviour increases. 
Subscriber requirements/wishes may demand that operators modify their system. In addition manufacturers improve the 
infrastructure components and add features to their products hence the operator will start modifying the PLMN network 
to profit from these changes and to improve subscriber satisfaction. Additionally, the PLMN network configuration will 
be modified (i.e. it will be up-dated or up-graded) to cope with a need for increasing or decreasing network capacity. 
These actions are carried out for the long-term strategy of the operators to optimise the network. 

4.1.3.1 System up-date 

Whenever the PLMN network needs to be improved for reasons of reducing failures, the system will be up-dated. In 
this case SW or equipment will be replaced without adding new functionality or resources to the network. The basic 
function required is: 

- the modification of existing SW/equipment; it may be necessary to introduce a different set of data to cope with 
the modified SW/equipment. 

For system up-date the network shall not be disturbed in its function until the required modification is activated. This 
requires mechanisms to: 

- do SW/data downloading in parallel with on-going traffic; 

- isolate the affected NEs/NRs from traffic before the actual modification is done; 

- minimise system outage due to the activation of up-dated components. 

4.1.3.2 System up-grade 

System up-grade may affect all areas of PLMN network activities and can be described as enhancements, whereby 
either new features or new facilities are implemented. This CM aspect also covers extensions, reductions or further 
replications of existing facilities. The CM functions employed are: 

- Creation of NEs and/or NRs; 

- Deletion of NEs and/or NRs; and 

- Modification of NEs and/or NRs. 
The following requirements are to apply: 

- to support expeditious handling of SW and data while minimising impact on ongoing traffic; 

- to follow a required sequence of up-grades: e.g. the new S W depends upon the availability of the new equipment 
functionahty; 

- to provide the capability to create an additional logical NE/NR without having installed the physical resource 
supporting it: for example it should be possible to create a cell in an RNC without the physical equipment 
present or connected. However, additional mechanisms should be in place to prevent any service connection to 
any physically non-existent NE/NR or reporting failures from non-existing NE/NR; 

- to provide the capability to install an additional physical NE/NR without creation of the logical resource 
managing it (no management functionality) and without impact of the current functionality; 

- to provide the capability to prevent the erroneous taking into service of a NE/NR which is not fully installed and 
initialised: whenever a NE/NR is modified (extension or reduction) it shall be taken out of service until the 
logical part of the procedure is finished. An extended NE/NR cannot be placed into service until all needed 
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parameters and equipment are initialised. Likewise, a reduced NE/NR cannot be placed back into service until 
the applicable re-configuration is performed. 

When the network is up-graded by the addition of NEs or NRs or a change in the configuration, it is essential that the 
NE/NR can be restored to the configuration, which existed before the changes were made. This procedure is called 
"reversion" and is useful in maintaining service if any difficulty should arise from a network up-grade. 



4.2 Operational context for CM 



The CM functions available to the operator need to address various aspects beyond that which might strictly be 
regarded as management of the network. These include: 

- assisting the operator in making the most timely and accurate changes thus avoiding lengthy waiting periods or 
complex scenarios; 

- ensuring that CM actions will not have any secondary effects on the network other than the specified ones; 

- providing mechanisms to protect the telecommunication-related traffic from effects due to CM actions - it shall 
be possible to inhibit traffic if a traffic affecting CM action is expected and to gracefully release calls prior to the 
closure of the resource; 

- providing mechanisms to overcome data inconsistency problems by logging the modifications for reversion 
reasons, or to recover through data update from a second source. 



4.2.1 Administrative aspects of CM 

When managing the network by creating, deleting or modifying NEs/NRs, the operator should ensure that there is no 
uncontrolled impact on the network. The network management system therefore needs to support the following set of 
management functionalities when addressing various administrative aspects: 

- Security; 

- Data Validity; 

- Data Consistency; and 

- Resource Administration. 

4.2.1.1 Security aspects 

It is ultimately up to the operator to ensure the network security by employing the appropriate mechanisms for control 
of logical and physical access. 

Changes of the network configuration shall be possible only for operators with appropriate authorisation profiles. 

4.2.1.2 Data validity 

It is the responsibility of all management systems and NEs that data input to and transferred between the systems is 
valid given the particular management context. 

4.2.1 .3 Data consistency and distribution of the MIB 

The Network Manager (NM) and Element Manager (EM) use different object model abstractions of the network's 
(NEs') physical and logical resources to be managed by these systems. This is the agreed Network Resource Model 
(NRM) between the NM and EM/NEs to be used at the Itf-N and EM-NE interface (see ref. 3GPP TS 32.102 [2] for the 
definition of these interfaces). The NRM of the Itf-N is fully standardised (see 3GPP TS 32.622 [3] and other IRPs 
containing NRMs, listed in the Introduction clause) while the NRM for the EM-NE interface is product-specific and is 
not standardised in this or related TSs. The NE local representation of those physical and logical instantiated resources 
to be managed, as well as their accurate mapping onto the agreed object model abstraction, is also product-specific. 
Thus the consistency between the actual local representation of physical and logical resources to be managed within an 
NE, and the corresponding view of the OS, relies on: 
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— Which information is exchanged between the NE and the management systems; For the EM-NE interface this is 
defined in a product-specific NRM, where the actual network infrastructure is modelled. This is internal to a 
specific development organisation and does not need to be open; thus it is not further discussed in the present 
document. In fact, by publishing the management information portion of these interfaces, too much of the 
internal design will be revealed and it may become impossible or at least very expensive and time-consuming to 
later enhance the systems using the interface. For the Itf-N between NM and EM/NE, the NRM as mentioned 
above is defined in 3GPP TS 32.622 [3] and other NRM IRPs listed in the Introduction clause. 

— How such information is exchanged between NE and management systems - this is for the Itf-N fully 
standardised by the present and related documents, while for the EM-NE interface only the protocol is 
standardised (cf. Figure 2 in 3GPP TS 32.102 [2]). 

— How information is locally represented and treated by an NE and by its associated (OSs); this is a product- 
specific choice of the manufacturers of NEs and OSs. 

— Where this information is kept; whether it is kept only at the "origin NEs" where the Managed Object Instances 
(MOIs) representing the managed NRs are created (NE-local MIB), or if also a copy of that information is kept 
in one or several of the OSs ("mirrored MIB"). This is again a product-specific choice of the manufacturers of 
NEs and OSs. If the "NE-local MIB" approach is chosen, the consistency "only" has to be maintained between 
the NEs, while if the "mirrored MIB" approach is chosen, the consistency has to be maintained between the NEs 
as well as the NM/EM and the NEs. 

A peer-to-peer data consistency between NM-EM and EM-NE does not guarantee overall data consistency from a 
network point of view. It is however possible for the NM to maintain consistency on the network level, as far as the 
information in the MIB for the Itf-N is concerned, by comparing related information (MOIs and attributes) in all 
connected systems (EMs and NEs) in the managed network. 

In order to promote data consistency, the following operational procedures are recommended: 

— Awareness of autonomous NE re-configuration: 

local NE re-configuration, for example partial or full reversion mechanisms (either triggered autonomously or by 
an operator), should always be reported; 

— Define appropriate audit procedures on the N- and EM-NE- interface to support MIB re-synchronisation: 
A. In case the "mirrored MIB" approach is chosen, take the following actions: 

1 . The NM shall be able to retrieve all management information from the EM and NE accessible via the Itf-N 
by applying appropriate data retrieval methods (periodically or on request); 

2. The NM shall after the retrieval compare the retrieved information with its own data and if necessary also 
compare related information between connected NEs (if the MIB stored in the NM already has been checked 
and found consistent, the latter step is not necessary); 

3. The NM shall report any deviations between the NE's view and the NM's view, and related NEs' views, to the 
operator; 

4. The NM shall automatically, or on operator command, after the check in step 2 above correct the deviating 
information in either the NM or the NEs (depending on whether the NEs or NM are regarded as "master" for 
the information; this is manufacturer dependent). 

B. In case the "NE-local MIB" approach is chosen the following actions shall be taken: 

1 . The NM shall be able to retrieve all management information from the EM and NE accessible via the Itf-N 
by applying appropriate data retrieval methods (periodically or on request); 

2. The NM shall after the retrieval compare the retrieved information between connected NEs; 

3. The NM shall report any deviations between the related NEs' views to the operator; 

4. The NM shall automatically, or on operator command, after the check in step 2 above correct the deviating 
information in the NEs. 

— If the "mirrored MIB" approach is chosen, the NM/EM view shall be maintained. As far as possible, operational 
concepts for data manipulation should employ the NM/EM as the only managing system for an NE. 
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If however access to local NE data is given to maintenance personnel, the following actions are recommended/ 
necessary in order to enable the NM/EM to maintain data consistency: 

- applying a remote OS terminal for the local access to the NE under consideration rather than directly 
modifying NE data without any control of the OS; 

- changes made locally shall be notified to the managing OS(s). 
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CM service components 



While a PLMN network is first installed and brought into service, and following installation the PLMN network 
operator will enhance and adapt the network to short and long term requirements. In addition, it will be optimised to 
satisfy customer needs. To cover these aspects of CM, the system will provide the operator with the following 
capabilities: 

- initial system installation to establish the network; 

- system operation to adapt the system to short term requirements; 

- system up-date whenever it is necessary to modify the system to overcome SW bugs or equipment faults; 

- system up-grade to enhance or extend the network by features or equipment respectively. 
These capabilities are provided by the management system through its service components: 

- system modification to change the network to meet the operators' requirements; 

- system monitoring to gain an overview on the present SW, equipment and data situation of the network. 
The service components will be explained in more detail in the following subclauses. 

5.1 System modification service component 

Whenever it is necessary to adapt the system data to a new requirement due to optimisation or new network 
configurations, it will require an operator action to introduce new or modified data into the system. The data will be 
distributed to: 

- either one EM/NE when dealing with a locally limited modification; or 

- each EM/NE concerned when the change affects multiple EM/NEs; and 

- the other NMs in the case where multiple NMs exist in the same management domain. 

This implies the necessity of mechanisms to ensure data integrity and to maintain system data consistency (cf subclause 
4.2.1.3). 

The concept of system modification includes the following aspects: 

- if subscriber traffic impacting data modifications are performed, the NEs/NRs concerned are first cleared from 
traffic in a controlled way; 

- the necessary modification is performed by the EM/NE; 

- only once all needed data is given to the system, are the concerned NEs/NRs put back into traffic again; 

- safeguards shall be available within the NEs to prevent changes to configuration affecting service(s) in use. 
In emergencies, it shall be possible to override these safeguards. 

On occasion, modifications may not be stable or not fulfil the operator intentions. In these cases, reversion to the 
previous stable configuration may be necessary. Occasionally there will be changes to the network that create a new 
configuration, which cannot revert to any previous network status for protection. Such changes may involve major 
equipment modification to the core elements of the network or re-distribution of traffic across interconnected nodes to 
other Operators. In these cases it is necessary to implement the changes and to manage the consequences of any 
problems or failures without the protection of 'reversion', as equipment may have been removed or the work programme 
may be complex, time limited and expensive. 

Progress of these changes should be sequential through an agreed milestone plan which includes effective tests to prove 
network functionality with only one action, or a coherent series of actions, completed at a time. The decision points, 
beyond which there is no return, should be clearly identified. 
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"Automatic re-configuration" shall not be dealt with in the present document as it is dependent on the implementation. 
However, if an automatic re-configuration occurs, the operator shall be informed of the result. 

5.2 System monitoring service component 

The system monitoring service component provides the operator with the ability to receive reports (on request or 
spontaneously) on the configuration of the entire network or parts of it from managed NEs. These consist of structure, 
states, versions employed and data settings. The NE sends spontaneous reports if there was an autonomous change of, 
for example, the states or other values due to Fault Management (FM) actions. Also, the NM may ask the managed 
EM/NE to send the information required to the NM at any time. 

The data that shall be possible to provide on request is a subset of, or the whole, MIB, which is an instantiation of the 
NRM, defined in 3GPP TS 32.622 [3] and other NRM IRPs listed in the Introduction clause. 

Any inconsistencies found during system monitoring by the NM should be reported to the operator, and it is left to the 
operator or an Operations System Function (OSF) to take appropriate actions. 



6 CM functions 

6.1 System modification functions 

The requirements of CM and their usage lead to basic CM functions to be defined for the network. These describe the 
required actions on managed elements (NEs or NRs) and the expected reactions. The system modification functions 
identified are: 

- Creation of Network Elements (NEs) and Network Resources (NRs); 

- Deletion of NEs and NRs; 

- Conditioning of NEs and NRs. 

For all identified functions, the following major requirements apply: 

- minimum disturbance of the network by taking the affected resources out of service if needed; 

- physical modifications should be independent of the related logical modifications; 

- all the required actions to satisfy a defined task should be completed correctly before the resources can be 
brought into service; 

- data consistency checks shall be performed as described in subclause 4.2.1.3. 
There are three aspects of NE and NR management, which can be distinguished: 

1) Management of the physical aspect (equipment); 

2) Management of the executable aspect (SW and FW); and 

3) Management of the logical/ functional aspect (data). 

All three management aspects are addressed by the present document. 
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6.1 .1 Creation of NEs and NRs 

The creation of a NE or NR is used to initially set up a PLMN network or to extend an already existing network. The 
action of creation is a combination of installation, initialisation and introduction of the newly installed equipment to the 
network and to the OS, which will control it. The creation can affect equipment, SW and data. 

Whenever a PLMN network or parts of it are installed, the created NEs/NRs require to be: 

- physically installed and tested and initialised with a possible default configuration; 

- logically installed by means of introduction to the network, possibly involving changes to related existing 
NE/NR configurations; 

- allowed to be put into service. 

The sequence of physical and logical installation may vary depending on the specific PLMN network operator strategy. 
In case the logical creation takes place before the physical creation no related alarms shall be reported to the operator. 

6.1 .2 Deletion of NEs and NRs 

If a network is found to be over-equipped, the operator may wish to reduce the scale of the network or to re-use the 
spare equipment elsewhere. This can occur when an operator over-estimates the traffic in one area and, for example, 
under-estimates the load in a different one. 

The deletion of a NE or NR requires: 

- taking the affected NEs or NRs out of service; 

- logical removal from the network (possibly involving changes to other NE or NR configurations, for example, 
neighbour cell description); 

- if necessary, the physical dismantling of the equipment; 

- return of other affected NEs or NRs to service. 

The sequence of logical and physical removal will not matter if the affected NEs are taken out of service prior to their 
removal. This will help to protect the network from error situations. 



6.1.3 Conditioning of NEs and NRs 



There are three categories of modifications to be regarded with respect to NEs or NRs. It is possible to either modify 
SW, equipment or data or a certain combination of them. Which aspects are affected by any particular modification is 
implementation dependent. 

When an MO/NR is to be modified the following actions shall be performed: 

- Locking or logical removal of the MO/NR (including first clearing it from traffic if necessary); 

- Required modification (physical and/or logical); and 

- Unlocking or logical re-installation of the MO/NR. 

This sequence is recommended to provide protection to the network against fault situations, which may occur during the 
modification process. By default, locking/modification/unlocking shall be the procedure to follow, and if logical 
removal/re-installation is necessary for a certain MO/NR, this shall be described in the NRM. 

The result of conditioning should be able to be determined by the operator by employing the appropriate mechanisms 
provided through the System Monitoring functions (see subclause 6.2). 

A modification to data, which has a controlling influence on some resources, could influence the resource throughput or 
its capability to originate new traffic during the modification time. This distinction is made because, for particular 
modifications, the capacity of the NR can be decreased without influencing the ongoing traffic. Before deciding to 
perform an action, the operator should consider the effects that a modification might have on capacity, throughput and 
current activity of a resource. 
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6.1 .3.1 Considerations on conditioning mechanisms 

The data, which characterise a PLMN network, will not all be subject to the same rate of change or need to be modified 
using the same mechanism. Changes to the logical configuration may also need to be applied across multiple NEs. 
These aspects are described in the following subclauses. 

Whenever the configuration of the network requires modification, the following questions will be important to the 
operator: 

- What will be the influence on the ongoing traffic? 

- What will be the impact on the capacity of the network? 

- How difficult and time-consuming will the modification procedure be? 

The answer to these questions will give an idea as to when the modification can be best performed with the aim to keep 
traffic disturbance as low as possible and to require the modification process itself to cause as little disturbance as 
possible. On the other hand, it does not seem to be reasonable to invent a "low disturbance" modification algorithm for 
each single parameter, especially those, which are only modified once or twice during the lifetime of the network. These 
rare modifications could be performed with an acceptable level of interruption to traffic. Therefore, the system data 
elements may be classified by: 

- modification once or twice during the life time of the system (e.g. protocol supervision timers); 

- modification required seldom; 

- modification is expected frequently and/or for a short term (telecom parameters). 

Depending on this rating the requirements on the modification mechanism for certain data elements should vary. 

6.1 .3.2 Network traffic considerations 

As stated previously, different types of modification mechanisms can be distinguished with regard to their impact on 
traffic and their extent: 

For the impact regarding traffic, the following types can be identified: 

- no impact on the traffic at all: 

the modified data values have no relation to the traffic capability; 

- impact on traffic: 

the data modification causes for example a change in the volume of allowable traffic without affecting existing 
traffic. 

For the impact regarding extent, the following types can be identified: 

- Impact on only the NR or NE 

The modification of SW, equipment or data is effective for a NR, or a complete NE. 

- Impact on more than one NE or different NRs of one NE 

Certain modifications on SW, equipment or data will require changes to be performed upon more than one NR in 
one NE or more than one NE. Such changes require consideration of data consistency, data integrity and network 
integrity. E.g. it should be distinguished between the NR directly affected by a modification and other impacted 
NRs. The relationships and dependencies between data values should be described and a mechanism defined to 
protect the system against inconsistency. 
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6.2 System monitoring functions 



A major aspect of CM is the ability of the operator to monitor the operation of the network. This monitoring capability 
is necessary for the operator to determine the current operational state of the network as well as to determine the 
consistency of information among various NEs. The monitoring capability requires three functions to support it: the 
information request function, the information report function and the response/report control function. 



6.2.1 Information request function 



In order to support the operator's need to monitor the network, the NM needs to be able to gather information on request 

from the various EMs and/or NEs. The EM may then act as a mediator for one or more NEs (how this is done is product 

specific and outside the scope of the present document). The information request function should support the 

capabilities of the NM to be able to request information for any single attribute defined in the management information 

base. 

In addition, the NM should be able to gather large amounts of information in a single request by providing appropriate 

scope and filtering constructs in the request. 

On receipt of a valid request, the addressed EM/NE shall respond with the current values of the specified data elements. 
This response will be immediate if so requested by the NM. However, in cases where very large amounts of data are 
concerned and where the EM and the NE support the capabilities, the NM may request the EM/NE to store the 
information in a file and transfer it using a file transfer mechanism. 

In case there is a communication failure when a response is to be sent, the response shall be safely stored and forwarded 
as soon as possible after re-establishment of communication. An exception that may inhibit this type of delayed 
response, is if the transaction has timed out in the requesting NM. 

6.2.2 Information report function 

In addition to being able to provide information on request, the NE is required to have the capability of reporting 
notifications about changed/removed information autonomously. Generally this will be performed when some 
information on the state or operation of the system has changed. The following shall be supported: 

The following type of events shall be notified to the NM, if enabled by the NM (these three notification types 
may be enabled/disabled separately by the NM): 

1. Object creation/deletion; 

2. Attribute value change; 

3. State change; 

Optionally: The above-mentioned notifications may be logged locally at the EM/NE. Logged notifications may 
be requested by the NM to be transferred from the EM/NE. Transfer mechanisms may be by file transfer or 
using messages; 

In case there is a communication failure when one or more notifications are to be forwarded, the notification(s) 
shall be safely stored and forwarded as soon as possible after re-establishment of communication. 



6.2.3 Response/report control function 



For responses to information requests and for information reports, it should be possible for the operator to specify where 
and when the information should go. The NM, EM and NE shall provide a capability to configure the 
response/reporting capabilities such that the following requirements are met at the Itf-N: 

- information forwarding shall be possible to be enabled and disabled; 

- information shall be possible to be forwarded to the NM as soon as it is available; 

- information shall be possible to be directed to any of various NMs (one or several). 
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7 Itf-N Interface 

7.1 CM principles 

The Itf-N (see ref. 3GPP TS 32.102 [2]) is an object oriented interface, i.e. all resources of the PLMN network 
(functional and physical resources) whose management is standardised by the present document are represented as 
Managed Object Instances (MOI) of a Network Resource Model (NRM). 

The NRM shall be highly simplified for the purpose of the NM, based on the assumption that all of the detailed CM 
actions, including fault correction after one or more alarms, are performed by an Element Manager (EM), which knows 
the vendor-specific NRM and configuration. 

The NRM identifies the basic Network Resources (NRs) to the level of detail required by FM and PM at the Network 
Management (NM) level. In addition to NR identification, the NRM also supports the alarm surveillance part of FM by 
defining which alarms can be notified by which Information Object Classes (lOCs). 

The definition of the Network Resource Model (NRM) for the Itf-N (connecting the NM with a "subordinate entity", 
which may be an EM or a NE) is described in 3GPP TS 32.622 [3] and other NRM IRPs listed in the Introduction 
clause, which define the Generic Network Resource Model and other specific NRMs applicable to PLMN management, 
such as the UTRAN NRM. 

This subclause describes the specific functional requirements related to CM of Network Resources (NRs) on the Itf-N. 

There are two types of CM functions: 

a) Passive CM (configuration overview), which mainly provides to the NM current information about the current 
configuration changes by means of notifications, and allows a retrieval and synchronisation of configuration related 
data on NM request. 

The forwarding of these notifications over the Itf-N is controlled by means of configuring adequate filtering 
mechanisms within the subordinate entities. The Itf-N also provides the means for storage ("logging") and later 
retrieval of desired information within the subordinate entities. 

b) Active CM, which offers to the NM operator a real capability to change the current network configuration. 
There are also at least two approaches to CM: Basic CM and Bulk CM. 

1 . Basic CM is characterised by 

a) The use of singular operations to retrieve (configuration parameters) over Itf-N from single NEs, or a 
collection of NEs. (The passive aspect of Basic CM) 

b) The use of singular operations to activate configuration parameters in EM/NEs over Itf-N. (The active aspect 
of Basic CM) 

2. Bulk CM is characterised by 

a) Bulk (file-oriented) data retrieval (configuration parameters) over Itf-N from single NEs, a collection of 
NEs or the whole network. (The passive aspect of Bulk CM) 

b) Bulk (file-oriented) data download of configuration parameters to EM/NEs over Itf-N. (An active aspect of 
Bulk CM) 

c) The network- wide activation of those parameters through a single operation. (An active aspect of Bulk CM) 

d) The ability to fallback to a previous stable configuration through a single operation. (An active aspect of 
Bulk CM) 
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7.2 Overview of IRPs related to CM 

The Itf-N for CM is built up by a number of Integration Reference Points (IRPs) and a related Name Convention, which 
realise the functional capabilities over this interface. The basic structure of the IRPs is defined in 3GPP TS 32.150 [9]. 
For CM, a number of IRPs (and a Name Convention) are defined, used by this as well as other specifications For 
Telecom Management (TM) produced by 3GPP. All these IRPs are defined in separate 3GPP specifications. 

7.3 Kernel CM 

The Kernel CM IRP provides the essential and common CM functions. A CM implementation will include the Kernel 
CM IRP and either one or both of the Basic CM IRP and the Bulk CM IRP. The Kernel CM IRP is specified in 
TS 32.661 through 32.664. 

The principal, but not the only, function of the Kernel CM IRP is to provide real-time forwarding of CM related event 
reports. During normal operation the NM is continuously informed by the managed subordinate entities about all 
network configuration changes, in accordance with the Network Resource Model (NRM) applied on the Itf-N. For this 
purpose the following CM-related event reports with regard to the ITU-T Recommendation X.721 [4], ITU- 
T Recommendation X.730 [5] and ITU-T Recommendation X.73 1 [6] are forwarded to the NM: 

Object creation; 

Object deletion; 

Attribute value change. 

The real-time forwarding of these event reports occurs via appropriate filtering mechanisms ("subscription" on CORBA 
interfaces) located in the subordinate entity in accordance with ITU-T Recommendation X.734 [7] or OMG 
event/notification service. These filters may be controlled (i.e. created, modified and eventually deleted) locally in the 
subordinate entities or remotely by the NM (via the Itf-N) in order to ensure that only the event reports which fulfil pre- 
defined criteria can reach the superior NM. In a multiple manager environment each NM may have its own filtering 
mechanism within every subordinate entity, which is able to generate CM-related notifications. 

It should be possible to pack multiple notifications together for sending to NM. This provides more efficient use of data 
communication resources. In order to pack multiple notifications, an EM/NE configurable parameter defines the 
maximum number of notifications to be packed together. Additionally an EM/NE configurable parameter defines the 
maximum time delay before the notifications have to be sent. 



£75/ 



3GPP TS 32.600 version 1 0.0.0 Release 10 19 ETSI TS 1 32 600 VI 0.0.0 (201 1 -05) 



7.4 Basic CM 

The Basic CM IRP provides a single operation style of CM as described for Basic CM in Clause 7.1. The Basic CM 
IRP is specified in TS 32.601 through 32.604. 

7.4.1 Passive CIVI - Retrieval/syncinronisation of CIVI-related information 

As long as the network is in operation and fault free, the update of the CM-related information on NM level is 
continuously ensured by the real-time forwarding of concerned reports as described in subclause 7.3.1. In case of faults 
(either on the NM or in a subordinate entity or on the communication link) it is possible that some CM-related event 
reports are lost. Therefore the CM-related information on the NM may become non-aligned with the real configuration 
of the network (depending on the strategy of the NM where to store network configuration information). In this case a 
synchronisation process may be necessary to align the CM-related information of the NM with the configuration 
information of the subordinate entities. 

The retrieval or synchronisation ("alignment") of network configuration information between the NM and one or more 
of its subordinate entities can be triggered at any time by the NM. 

There are two different alternatives for this synchronisation: 

via a read command with appropriate filtering; 

as an ordered sequence of CM-related event reports. 

7.4.2 Active CM 

The optional Active CM functions of the Basic CM IRP provide the ability to modify Network Resources. There are 
three active CM functions: 

Create a Managed Object instance 

Delete a Managed Object instance(s) 

Modify the attributes of a Managed Object instance(s). 

7.5 Bulk CM 

The Bulk CM IRP provides efficient mechanisms to upload current CM data from the IRP Agent and download new 
CM data to the IRP Agent and to activate the new CM data. Bulk CM provides both active and passive CM functions as 
described in Clause 7.1. The Bulk CM IRP is specified in TS 32.611 through 32.615. 

Bulk CM can transfer a CM file containing, for example, radio network parameters from the NM to the IRP Agent 
using a standardised file format and transfer mechanism. The IRP Agent shall also be capable of making the necessary 
configuration changes in its managed NEs, using the parameters and information contained in the transferred CM file. 
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7.6 Common CM and NRM IRP Requirements 
7.6.1 General 

The following requirements apply to and are referenced by all CM and NRM IRPs: 

Any implementation of a CM IRP must also include the implementation of the Kernel CM IRP in order to claim 
3GPP conformance. 

For each Information Object Class (IOC) specified in an NRM IRP, the specification shall: 

Specify whether instances of the IOC may be created over the Itf-N. 

Specify whether instances of the IOC may be deleted over the Itf-N. 

Specify whether instances of the IOC may be modified over the Itf-N by indicating whether at least one 
attribute of the instance may be modified (i.e., is ReadAVrite). 

Specify default values for the attributes of the IOC. When default values are specified for a IOC, each 
attribute may be given a single value (of the same type as the attribute), may be specified as vendor-specific 
(in which case no specific value is specified) or may be specified as having 'no default'. These default values 
may be used when an instance of the IOC is created or when attribute values are modified. How default 
attribute values are specifically to be used shall be specified in the Basic and Bulk CM IRP Information 
Specifications. The default values are applicable to both Basic and Bulk CM as well as to CM operations 
initiated by the agent itself. 

Specify the name of the naming attribute (see [8]) as 'id' for all lOCs defined in Release 9 and later. 



£75/ 



3GPP TS 32.600 version 10.0.0 Release 10 



21 



ETSI TS 132 600 VI 0.0.0 (2011-05) 



Annex A: 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Jun 2001 


SA 12 


SP-010283 


-- 


-- 


Approved at TSG SA #12 and placed under Change Control 


2.0.0 


4.0.0 


Sep 2002 


SA 17 


SP-020483 


001 


-- 


Add Kernel CM, Revise Basic (adding Active CM) and Bulk CM 


4.0.0 


5.0.0 


Jun 2003 


-- 


-- 


-- 


-- 


Editorial change: Title aligned with the 3GPP Database 


5.0.0 


5.0.1 


Mar 2004 


SA 23 


SP-040105 


-- 


-- 


Automatic upgrade to Rel-6 (no CR) 


5.0.1 


6.0.0 


Jun 2007 


SA_36 


- 


- 


- 


Automatic upgrade to Rel-7 (no CR) at freeze of Rel-7. Deleted 
reference to CMIP SS, discontinued from R7 onwards. 


6.0.0 


7.0.0 


Dec 2008 


SA 42 


-- 


-- 


-- 


Upgrade to Release 8 


7.0.0 


8.0.0 


Sep 2009 


SA 45 


SP-090627 


002 


-- 


Introduce rule for IOC attribute naming 


8.0.0 


9.0.0 


May 2010 


- 


- 


- 


- 


Removal of revision marks 


9.0.0 


9.0.1 


Jun 2010 


SA 48 


SP-1 00264 


003 


-- 


Removal of '3G/UMTS' restriction and cleanup of definitions 


9.0.1 


10.0.0 



£75/ 



3GPP TS 32.600 version 10.0.0 Release 10 



22 



ETSI TS 132 600 VI 0.0.0 (2011-05) 



History 



Document history 


VIO.0.0 


May 2011 


Publication 



























£75/ 



